Unit testing guide #78
Conversation
prettier few changes
|
|
||
| Now our project should look something like this: | ||
|
|
||
|  |
There was a problem hiding this comment.
Use text instead if possible (see above)
If not provide a accurate alt-text description e.g: "File Explorer of vscode showing directory X, File Y... with a red border around File Y..."
|
|
||
| So to start off, you’re gonna need some project set up, the specifics don’t really matter, you can just take these ideas and extrapolate them to your own needs, but for demonstration I’m going to have a basic project set up like this: | ||
|
|
||
|  |
There was a problem hiding this comment.
Use Text instead e.g.
- dirOne
- dirTwo
- file1
...
Or a descriptive Alt text:
"Directory structure showing Directory X with Files X,Y,Z"
| Now hit compile and change your terminals directory in to your tstl output folder, for me it’s the `dist` folder. | ||
| We can now just simply run `busted`, and you should see something like this: | ||
|
|
||
|  |
There was a problem hiding this comment.
Provide a more accurate alt text actually describing the contents of the image.
| @@ -0,0 +1,262 @@ | |||
| --- | |||
| title: Unit Testing | |||
There was a problem hiding this comment.
| title: Unit Testing | |
| title: Unit Testing With Busted |
|
|
||
| This is where unit testing comes in, say a piece of code depends on this function working like it does, and for it to keep working exactly like it does right now, obviously you could use the tried and true method of doing the testing yourself, but unit testing provides an alternative to the manual work. | ||
|
|
||
| So, unit testing, where do we begin? |
There was a problem hiding this comment.
Suggestion: Start a new section here titled 'Unit tests with Busted'
| }; | ||
| ``` | ||
|
|
||
| So our function takes an array of numbers like “[1,2,3,4]” and returns a string like “1,2,3,4” or “4,3,2,1”. |
There was a problem hiding this comment.
| So our function takes an array of numbers like “[1,2,3,4]” and returns a string like “1,2,3,4” or “4,3,2,1”. | |
| So our function takes an array of numbers like `[1,2,3,4]` and returns a string like “1,2,3,4” or “4,3,2,1”. |
|
|
||
| Now that we have busted installed and the `busted` command runs in your terminal of choice successfully we can proceed. | ||
|
|
||
| Let’s quickly install busted typings like so `npm install -d busted-tstl` |
There was a problem hiding this comment.
| Let’s quickly install busted typings like so `npm install -d busted-tstl` | |
| Install busted type declarations into your project using `npm install -d busted-tstl` |
|
|
||
| Let’s quickly install busted typings like so `npm install -d busted-tstl` | ||
|
|
||
| And we need to add busted-tstl types to our tsconfig.json, you should already have a section like this: |
There was a problem hiding this comment.
This is only required in the tsconfig in your test directory, also in your example repository I would suggest moving tsconfig.test.json to spec/tsconfig.json, so you are not polluting your main codebase with testing stuff.
There was a problem hiding this comment.
I would not assume people already have types in their tsconfig, and I think it would be a good idea to mention compilerOptions, like we do on the language extensions page.
|
|
||
| So the short version of what’s happening there is the ‘describe’ block is our named collection of tests, this collection tests the library function, so we've named it `"Library Function"` | ||
|
|
||
| Next we call it(‘’,()=>{}) in there to name and describe the behaviour of a single test, it’s a regular function, so you can call and do anything in there. Here, we’re just using a function in the assert namespace which passes the test if the 2 parameters are exactly equal, and fails if they’re different. |
There was a problem hiding this comment.
| Next we call it(‘’,()=>{}) in there to name and describe the behaviour of a single test, it’s a regular function, so you can call and do anything in there. Here, we’re just using a function in the assert namespace which passes the test if the 2 parameters are exactly equal, and fails if they’re different. | |
| Next we call `it(‘’,()=>{})` in there to name and describe the behaviour of a single test, it’s a regular function, so you can call and do anything in there. Here, we’re just using a function in the assert namespace which passes the test if the 2 parameters are exactly equal, and fails if they’re different. |
(Added preformat/code backticks)
| }); | ||
| ``` | ||
|
|
||
| Now hit compile and change your terminals directory in to your tstl output folder, for me it’s the `dist` folder. |
There was a problem hiding this comment.
Would be nice to set this up as part of your TS workspace. To do this you can specify a custom 'test' script in package.json that builds and executes tests. An example of how I would set up my package.json in project root for your example repo:
{
...
"scripts": {
...
"pretest": "tstl -p spec",
"test": "busted spec",
...
}
}This would mean you no longer need to switch between directories. It also means you can build and execute your tests by simply running npm test, which is the standard way of running tests for node projects.
Have a look at the TypeScriptToLua package.json as an example:
|
|
||
| ## TSTL Library specifics | ||
|
|
||
| This section applies to projects described in [Publishing Modules](publishing-modules.md), as you might know, library projects don’t (and shouldn’t) include the luaLibBundle and also any dependencies it would need to run, so how do we make it run standalone, for testing, we’re going to utilize the fact that you can pass in a different `tsconfig.json` to the compiler, so, the regular one is implicitly used based on the name `tsconfig.json`, we’re going to create a new one like `tsconfig.test.json` you can pretty much duplicate it from your current one, we’re just going to change a few values: |
There was a problem hiding this comment.
Why are you suddenly mentioning luaLibBundle here? this is the first time that's referenced in this article, and I don't see how it is relevant - shouldn't be needed for busted right?
There was a problem hiding this comment.
This is a weird setup, why not have a tsconfig.json inside your /spec/ directory? It should also be possible to just give that its own dist (or just do no outdir and just have lua next to TS files in that directory).
|
|
||
| Then you can edit your `package.json` file and add a new task: | ||
|
|
||
| ```json title=package.json |
There was a problem hiding this comment.
using diff instead of json highlighting might be better for this one:
"scripts": {
"build": "tstl",
"dev": "tstl --watch",
+ "pretest": "tstl --project spec/tsconfig.json",
+ "test": "busted spec"
},
Added a new guide/section that explores busted testing & automating those tests with github actions.